--- /dev/null
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-05-16T16:32:51Z"
+ content="""
+sync's intent is to replicate as close as possible the following common
+git workflow:
+
+ first stage some changes, and then run:
+ git commit -m foo
+ git pull
+ git push
+
+Since git-annex has some complications involving pulling and pushing
+the git-annex branch, and transferring the content, it adds a learning
+curve that was too high. Giving users one new command to learn minimizes
+the learning curve. (It's unfortunate it didn't originally send content,
+and annex.synccontent aims to fix that oversight and I hope it may eventually
+become default.)
+
+For git-annex sync to default to doing something not in the above
+pull+commit+push workflow would be surprising, because that's the workflow
+users have been told it handles.
+
+Notice that the git-annex assistant will happily add all files to the
+repository and send their content. That's because it's *not* targeting
+users who expect to use that git workflow. So it's not surprising that it
+does what it does.
+
+In conclusion, if having this behavior enabled by git config is not useful,
+then it does not belong in `git-annex sync`. It could go in a new command.
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-05-16T17:05:35Z"
+ content="""
+I also generally feel like `git-annex sync` was probably a bad conflation
+of 3 git commands into 1 command when there could have just been `git-annex
+pull` and `git-annex push`. The fact that it conflates several things makes
+users think of it as just a big "does all the things" command, which makes
+users want it to do more things.
+
+It is not too late to split it up, and eventually deprecating it would be a
+good path to making annex.synccontent default.
+"""]]